Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/java/com/web/SearchWeb/config/security/SecurityUtils.java`:
- Around line 25-30: In SecurityUtils (the method that extracts memberId from
the authentication principal), ensure you fail-closed by validating the returned
memberId from CustomUserDetails.getMemberId() and
CustomOAuth2User.getMemberId(): if either is null throw an UNAUTHORIZED response
(e.g. throw ResponseStatusException(HttpStatus.UNAUTHORIZED) or your app's
equivalent) instead of returning null; also handle the fallback branch (when
principal is not one of those types) to throw UNAUTHORIZED so no null memberId
propagates.

In
`@src/main/java/com/web/SearchWeb/folder/controller/dto/MemberFolderRequests.java`:
- Around line 17-27: Change the DTO fields from public to private so external
code cannot mutate them after validation; in the nested request class Create
make parentFolderId, folderName, and description private and rely on the
existing `@Getter` (and default constructor) for Jackson/Bean Validation, and
apply the same change to the other nested request classes in this file (e.g.,
Update/other request classes that currently have public fields).

In `@src/main/java/com/web/SearchWeb/folder/error/FolderErrorCode.java`:
- Line 13: The enum constant FOLDER_FORBIDDEN in FolderErrorCode currently uses
the incorrect code string "Foo3"; update the enum entry for FOLDER_FORBIDDEN to
use the correct code "F003" so the exposed error code matches the response
contract and client documentation.

In `@src/main/java/com/web/SearchWeb/folder/error/FolderException.java`:
- Line 10: The FolderException constructor currently accepts the generic
ErrorCode which allows non-folder error codes to be passed; change the
constructor signature in class FolderException to accept FolderErrorCode instead
(replace ErrorCode parameter with FolderErrorCode) and update all call sites
that construct new FolderException(...) to pass a FolderErrorCode (adjust
imports/usages as needed) so the API boundary is type-safe; keep the rest of
FolderException behavior unchanged.

In `@src/main/java/com/web/SearchWeb/folder/service/MemberFolderService.java`:
- Around line 13-15: Remove the redundant ownerMemberId parameter from the
MemberFolderService API: change the signatures of listRootFolders and
listChildren to accept only Long loginId (and Long parentFolderId for
listChildren), and update all implementations to derive the owner from loginId
instead of using ownerMemberId; also remove or adapt calls to
validateOwner(loginId, ownerMemberId) so they validate ownership using loginId
alone (e.g., validateOwner(loginId) or inline owner resolution) and adjust any
controllers/routes to stop passing ownerMemberId.

In `@src/main/java/com/web/SearchWeb/folder/service/MemberFolderServiceImpl.java`:
- Around line 220-235: validateNoCycle currently walks parent links and issues a
DB call per level via memberFolderJpaRepository.findById, which can be slow for
deep hierarchies; replace or supplement this with a single recursive query (CTE)
in the repository to fetch the ancestor chain (or perform a direct cycle check)
and use that result to detect folderId in the ancestors, updating
validateNoCycle to call the new repository method instead of looping; reference
validateNoCycle, memberFolderJpaRepository.findById, and the
FolderException/FOLDER_NOT_FOUND and INVALID_FOLDER_MOVE error codes when adding
the repository method and adjusting the service logic.
- Around line 80-91: normalizeDescription currently trims and null-checks but
lacks the max-length validation present in normalizeFolderName; add a length
check to ensure the returned description does not exceed the MemberFolder
`@Column`(length = 500) constraint. Modify normalizeDescription to trim, return
null for empty, then if length > 500 either truncate to 500 or throw an
IllegalArgumentException (match the approach used in normalizeFolderName), and
prefer introducing/using a named constant (e.g., MAX_DESCRIPTION_LENGTH = 500)
to make the limit explicit.
- Around line 68-78: The service validation in normalizeFolderName enforces a
50-character limit that conflicts with MemberFolder.folderName which is
annotated `@Column`(length = 100); fix by making the constraints consistent:
either update normalizeFolderName to allow up to 100 characters (replace the 50
check) or change the MemberFolder.folderName column length to 50 and update any
DB migrations; ensure FolderException uses FolderErrorCode.INVALID_FOLDER_NAME
as before and, if the shorter 50 limit is intentional, add a clear comment or
Javadoc near MemberFolder.folderName and normalizeFolderName documenting the
business rule.

---

Outside diff comments:
In
`@src/main/java/com/web/SearchWeb/config/security/CustomAuthenticationSuccessHandler.java`:
- Around line 17-21: The redirectUrl parameter in
CustomAuthenticationSuccessHandler is used directly in response.sendRedirect,
causing an open-redirect risk; update the onAuthenticationSuccess logic to
validate redirectUrl before redirecting: parse the redirectUrl (variable
redirectUrl) and only allow redirection if it is a safe relative path (starts
with "/" but not "//" or contains protocol) or matches an explicit allowlist of
trusted domains, otherwise fall back to the default target (e.g.,
defaultTargetUrl or savedRequestRedirect). Ensure this validation occurs
immediately before the call to response.sendRedirect and reject/ignore unsafe
values.

In `@src/main/java/com/web/SearchWeb/config/security/SecurityConfig.java`:
- Around line 110-118: SecurityConfig currently defines beans
customAuthenticationFailureHandler() and customAuthenticationSuccessHandler()
which duplicate the existing `@Component-scanned`
CustomAuthenticationFailureHandler and CustomAuthenticationSuccessHandler;
remove these `@Bean` methods and instead inject the existing beans into
SecurityConfig via constructor injection (add constructor parameters
CustomAuthenticationFailureHandler and CustomAuthenticationSuccessHandler) and
use those injected instances inside the filterChain method; alternatively, if
you prefer explicit bean factory methods, remove the `@Component` annotation from
the handler classes so only the `@Bean` factory methods produce instances.

In `@src/main/java/com/web/SearchWeb/tag/error/TagErrorCode.java`:
- Line 11: Rename the enum constant Tag_NOT_FOUND to follow SCREAMING_SNAKE_CASE
as TAG_NOT_FOUND in TagErrorCode (change the symbol Tag_NOT_FOUND ->
TAG_NOT_FOUND) and update all references, e.g., in TagException (replace
TagErrorCode.Tag_NOT_FOUND with TagErrorCode.TAG_NOT_FOUND) so naming is
consistent with other constants like DUPLICATE_BOOKMARK and FOLDER_NOT_FOUND.